home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-rekhter-cidr-environment-00.txt < prev    next >
Text File  |  1993-04-15  |  20KB  |  559 lines
  1.                                   - 1 -
  2.  
  3.  
  4.  
  5. Network Working Group                                      Y. Rekhter
  6. INTERNET DRAFT                 T.J. Watson Research Center, IBM Corp.
  7.                                                           C. Topolcic
  8.                                                                  CNRI
  9.                                                            April 1993
  10.  
  11.  
  12.  
  13.  Exchanging Routing Information Across Provider/Subscriber Boundaries
  14.                         in the CIDR Environment
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This document is an Internet Draft.  Internet Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its Areas,
  21.    and its Working Groups.  Note that other groups may also distribute
  22.    working documents as Internet Drafts.
  23.  
  24.    Internet Drafts are draft documents valid for a maximum of six
  25.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  26.    other documents at any time.  It is not appropriate to use Internet
  27.    Drafts as reference material or to cite them other than as a
  28.    ``working draft'' or ``work in progress.''
  29.  
  30.    Please check the 1id-abstracts.txt listing contained in the
  31.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  32.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  33.    current status of any Internet Draft.
  34.  
  35.  
  36. 1   Introduction
  37.  
  38.  
  39.    Classless Inter-Domain Routing (CIDR) has been adopted as a solution
  40.    to the scaling problem in the Internet. The overall CIDR architecture
  41.    is described in [1]. The architecture for IP address assignment with
  42.    CIDR is covered in [2] and [3]. The inter-domain routing protocols
  43.    that are capable of supporting CIDR are covered in [4], [5], and [6].
  44.  
  45.    The purpose of this document is twofold. First, it describes various
  46.    alternatives of exchanging inter-domain routing information across
  47.    domain boundaries, where one of the peering domain is CIDR-capable
  48.    and another is not.  Second, it addresses the implications of running
  49.    CIDR-capable inter-domain routing protocols (e.g. BGP-4, IDRP) on
  50.    intra-domain routing.
  51.  
  52.    This document is not intended to cover all the cases (either real or
  53.    imaginable). Rather, it focuses on what is viewed to be the most
  54.    common cases.  We expect that individual service
  55.    providers/subscribers will use this document as guidelines in
  56.  
  57.  
  58.  
  59.  
  60.  
  61. Expiration Date October 1993                                    [Page 1]
  62.  
  63.                            - 2 -
  64.  
  65.  
  66.  
  67.    establishing specific operational plans that would deal with
  68.    transition to CIDR.
  69.  
  70.    Throughout the document we use the concepts of "network service
  71.    provider" and "network service subscriber". These concepts were
  72.    introduced in [3]. For the sake of brevity we'll use terms "service
  73.    provider" and "service subscriber", rather than "network service
  74.    provider" or "network service subscriber".
  75.  
  76.    This document defines a CIDR-capable provider/subscriber as the
  77.    provider/subscriber that can perform correct IP packet forwarding
  78.    (both internally and to other adjacent providers/subscribers) when
  79.    the inter-domain routing information acquired by the
  80.    provider/subscriber is expressed solely in terms of IP address
  81.    prefixes (with no distinction between A/B/C class of addresses).
  82.  
  83.    This document defines CIDR-capable forwarding as the ability of a
  84.    router to maintain its forwarding table and to perform correct
  85.    forwarding of IP packets without making any assumptions about the
  86.    class of IP addresses.
  87.  
  88.    This document defines CIDR reachability information as reachability
  89.    information that may violate any assumptions about the class of IP
  90.    addresses. For instance, a contiguous block of class C networks
  91.    expressed as a single IP address prefix constitutes CIDR reachability
  92.    information.
  93.  
  94.  
  95. 2   Taxonomy of Service Providers and Service Subscribers
  96.  
  97.  
  98.    For the purpose of this document we partition all service providers
  99.    and service subscribers into the following categories, based on the
  100.    type and volume of inter-domain routing information a
  101.    provider/subscriber needs to acquire in order to meet its service
  102.    requirements:
  103.  
  104.  
  105.       - Requirements imposed on a service provider/subscriber preclude
  106.         it from using Default inter-domain route(s) -- we'll refer to
  107.         such a provider/subscriber as a Type 1 provider/subscriber.
  108.  
  109.       - Requirements imposed on a service provider/subscriber allow it
  110.         to rely on using one or more Default routes for inter-domain
  111.         routing, but this information must be supplemented by requiring
  112.         the provider/subscriber to acquire a large percentage of total
  113.         Internet routing information -- we'll refer to such a
  114.         provider/subscriber as a Type 2 provider/subscriber.
  115.  
  116.       - Requirements imposed on a service provider/subscriber allow it
  117.         to rely on using one or more Default routes for inter-domain
  118.  
  119.  
  120.  
  121.  
  122.  
  123. Expiration Date October 1993                                    [Page 2]
  124.  
  125.                            - 3 -
  126.  
  127.  
  128.  
  129.         routing; however, to meet its service requirements the
  130.         provider/subscriber must supplement Default route(s) by
  131.         acquiring a small percentage of total Internet routing
  132.         information -- we'll refer to such a provider/subscriber as a
  133.         Type 3 provider/subscriber.
  134.  
  135.       - Requirements imposed on a service subscriber allow it to rely
  136.         solely on using one or more Default routes for inter-domain
  137.         routing; no other inter-domain routing information need to be
  138.         acquired -- we'll refer to such a subscriber as a Type 4
  139.         subscriber.
  140.  
  141.  
  142. 3   Assumptions on Deployment of CIDR in the Internet
  143.  
  144.  
  145.    The document assumes that the CIDR deployment in the Internet will
  146.    proceed as a multi-phase process.
  147.  
  148.    In the first phase all the major service providers will become CIDR-
  149.    capable. Specifically, all the providers that can't rely on using
  150.    Default route(s) for inter-domain routing (Type 1 providers) are
  151.    expected to deploy BGP-4 and transition to CIDR during this phase. It
  152.    is expected that CIDR reachability information will first appear in
  153.    the Internet upon transition of all Type 1 service
  154.    providers/subscribers to CIDR.
  155.  
  156.    The second phase will commence upon completion of the first phase.
  157.    During the second phase other service providers/subscribers that are
  158.    connected to the service providers that were transitioned to CIDR
  159.    during the first phase will become CIDR-capable.  Specifically,
  160.    during the second phase it is expected that most of the
  161.    providers/subscribers that need to acquire a large percentage of the
  162.    total Internet routing information (Type 2 provider/subscriber) will
  163.    become CIDR-capable.  In addition, during the second phase some of
  164.    the Type 3 providers/subscribers may become CIDR-capable as well.
  165.    This plan was agreed to by a number of major providers [8]. NSFNET's
  166.    steps to implement this plan are described in [9].
  167.  
  168.    Finally, during the third phase the rest of the Type 3
  169.    providers/subscribers and most of the Type 4 subscribers will
  170.    transition to CIDR.
  171.  
  172.    It is expected that duration of the first phase will be significantly
  173.    shorter than duration of the second phase.  Likewise, duration of the
  174.    second phase is expected to be shorter than duration of the third
  175.    phase.
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185. Expiration Date October 1993                                    [Page 3]
  186.  
  187.                            - 4 -
  188.  
  189.  
  190.  
  191. 4   Implications of CIDR on Interior Routing
  192.  
  193.  
  194.    A CIDR-capable service provider/subscriber can use the following two
  195.    techniques to distribute exterior routing information to all of its
  196.    routers (both interior and border):
  197.  
  198.  
  199.       - utilize internal BGP/IDRP between all the routers
  200.  
  201.       - use CIDR-capable IGPs (e.g. OSPF, IS-IS, RIP2)
  202.  
  203.    The first technique doesn't impose any addition requirements on the
  204.    IGP within the provider/subscriber. Additional information on
  205.    implementing the first option is presented in [5] (see Section
  206.    A.2.4).
  207.  
  208.    The second technique allows the provider/subscriber to reduce the
  209.    utilization of internal BGP/IDRP, but imposes specific requirements
  210.    on the intra-domain routing. It also requires the ability to inject
  211.    inter-domain routing information (acquired either via BGP or IDRP)
  212.    into the intra-domain routing. Additional details on implementing the
  213.    second option are provided in [7]. It is not expected that all the
  214.    features enumerated in [7] will be widely needed. Therefore, it would
  215.    be highly desirable to prioritize the features.
  216.  
  217.    Note that both of these techniques imply that all the routers within
  218.    a CIDR-capable service provider/subscriber need to be capable of
  219.    CIDR-based forwarding.
  220.  
  221.    Discussion of which of the two techniques should be preferred is
  222.    outside the scope of this document.
  223.  
  224.  
  225. 5   Exchanging Inter-Domain Routing Information
  226.  
  227.  
  228.    At each phase during the transition to CIDR one of the essential
  229.    aspects of the Internet operations will be the exchange of inter-
  230.    domain routing information between CIDR-capable providers/subscribers
  231.    and CIDR-incapable provider/subscribers.
  232.  
  233.    When exchanging inter-domain routing information between a CIDR-
  234.    capable provider/subscriber and a CIDR-incapable provider/subscriber,
  235.    it is of utmost importance to take into account the view each side
  236.    wants of the other to present. This view has two distinct aspects:
  237.  
  238.  
  239.       - the type of routing information exchanged (e.g. Default route,
  240.         traditional (non-CIDR) reachability information, CIDR
  241.         reachability information)
  242.  
  243.  
  244.  
  245.  
  246.  
  247. Expiration Date October 1993                                    [Page 4]
  248.  
  249.                            - 5 -
  250.  
  251.  
  252.  
  253.       - routing information processing each side needs to do to maintain
  254.         these views (e.g. ability to perform aggregation, ability to
  255.         perform controlled de-aggregation)
  256.  
  257.    The exchange of inter-domain routing information is expected to be
  258.    controlled by bilateral agreements between the directly connected
  259.    service providers/subscribers. Consequently, the views each side
  260.    wants of the other are expected to form an essential component of
  261.    such agreements.
  262.  
  263.    To facilitate troubleshooting and problem isolation, the bilateral
  264.    agreements should be made accessible to other providers/subscribers.
  265.    One way to accomplish this is by placing them in a generally
  266.    accessible database. The details of how this can be implemented are
  267.    outside the scope of this document. A possible way to accomplish this
  268.    is described in [9].
  269.  
  270.    Since the exchange of inter-domain routing information across
  271.    provider/subscriber boundaries occurs on a per peer basis, a border
  272.    router is expected to provide necessary mechanisms (e.g.
  273.    configuration) that will control exchange and processing of this
  274.    information on a per peer basis.
  275.  
  276.    In the following sections we describe possible scenarios for
  277.    exchanging inter-domain routing information. It is always assumed
  278.    that one side is CIDR-capable and the other is not.
  279.  
  280.  
  281. 5.1 Exchanging Inter-Domain Routing Information between CIDR-capable
  282.     providers and CIDR-incapable Type 2 (default with large proportion of
  283.     explicit routes) providers/subscribers
  284.  
  285.  
  286.    When a CIDR-capable provider receives inter-domain routing
  287.    information from a CIDR-incapable Type 2 provider/subscriber, it is
  288.    expected that the border router(s) within the CIDR-capable provider
  289.    will be capable of performing aggregation of this information. The
  290.    aggregation is expected to be governed and controlled via a bilateral
  291.    agreement.  Specifically, the CIDR capable provider is expected to
  292.    aggregate only the information the other side (the CIDR-incapable
  293.    provider/subscriber) requests. In other words, the aggregation shall
  294.    only be done on agreement by the recipient (the CIDR-capable
  295.    provider).
  296.  
  297.    Passing inter-domain routing information from a CIDR-capable provider
  298.    to a CIDR-incapable Type 2 provider/subscriber will require an
  299.    agreement between the two that would cover the following items:
  300.  
  301.       - under what conditions the CIDR-capable provider can pass an
  302.         inter-domain Default route to the CIDR-incapable
  303.         provider/subscriber
  304.  
  305.  
  306.  
  307.  
  308.  
  309. Expiration Date October 1993                                    [Page 5]
  310.  
  311.                            - 6 -
  312.  
  313.  
  314.  
  315.       - exchange of specific non-CIDR reachability information
  316.  
  317.       - controlled de-aggregation of CIDR reachability information
  318.  
  319.    Agreements that cover the first two items are already implemented
  320.    within the Internet. Thus, the only additional factor introduced by
  321.    CIDR is the third item. A CIDR-capable provider may decide not to
  322.    de-aggregate any CIDR reachability information, or to de-aggregate
  323.    some or all of the CIDR reachability information.
  324.  
  325.    If a CIDR-capable provider does not de-aggregate CIDR reachability
  326.    information, then its non-CIDR Type 2 peer can obtain reachability
  327.    information from it either as non-CIDR reachability information
  328.    (explicit Class A/B/C network advertisement) or as an inter-domain
  329.    Default route.  Since most of the current reachability information in
  330.    the Internet is non-CIDR, a Type 2 provider/subscriber would be able
  331.    to acquire this information as explicit Class A/B/C network
  332.    advertisements from the CIDR-capable provider, as it does now.
  333.    Further, it is expected that at least on a temporary basis (until the
  334.    completion of the second phase of the transition) in a majority of
  335.    cases, Type 2 providers/subscribers should be able to use an inter-
  336.    domain Default route (acquired from the CIDR-capable provider) as a
  337.    way of dealing with forwarding to destinations covered by CIDR
  338.    reachability information.
  339.  
  340.    Thus, it is expected that most of the cases when dealing with Type 2
  341.    providers/subscribers could be addressed by a combination of
  342.    exchanging specific non-CIDR reachability information and an inter-
  343.    domain Default route. Any inconvenience to a provider/subscriber due
  344.    to the use of an inter-domain Default route will be removed once the
  345.    provider/subscriber transitions to CIDR.
  346.  
  347.    On the other hand, a CIDR-capable provider may decide to perform
  348.    controlled de-aggregation of CIDR reachability information.
  349.    Additional information on performing controlled de-aggregation can be
  350.    found in [5] (Section 8).  Special care must be taken when de-
  351.    aggregating CIDR reachability information carried by a route with the
  352.    ATOMIC_AGGREGATE path attribute.  It is worth while to point out that
  353.    due to the nature of Type 2 provider/subscriber (it needs to acquire
  354.    a large percentage of total inter-domain routing information) it is
  355.    expected that the controlled de-aggregation would result in a non-
  356.    negligible configuration at the border router that performs the de-
  357.    aggregation.
  358.  
  359.  
  360.  
  361. 5.2  Exchanging Inter-Domain Routing Information between CIDR-capable
  362.      providers and CIDR-incapable Type 3 (Default with few explicit routes)
  363.      providers/subscribers
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371. Expiration Date October 1993                                    [Page 6]
  372.  
  373.                            - 7 -
  374.  
  375.  
  376.  
  377.    The only difference between this case and the case described in
  378.    Section 5.1 is the fact that a CIDR-incapable provider/subscriber
  379.    requires just a small percentage of total inter-domain routing
  380.    information. If this information falls into a non-CIDR category, then
  381.    a Type 3 provider/subscriber would be able to acquire it from a
  382.    CIDR-capable provider. If this is CIDR reachability information, then
  383.    in a majority of cases it is expected that forwarding to destinations
  384.    covered by this information could be handled via an inter-domain
  385.    Default route.
  386.  
  387.    It is still expected that a border router in a CIDR-capable provider
  388.    would be able to aggregate routing information it receives from a
  389.    CIDR-incapable Type 3 provider/subscriber. The aggregation is
  390.    expected to be governed and controlled via a bilateral agreement.
  391.    Specifically, the CIDR capable provider is expected to aggregate only
  392.    the information the other side (the CIDR-incapable
  393.    provider/subscriber) requests.
  394.  
  395. 5.3  Exchanging Inter-Domain Routing Information between CIDR-capable
  396.      providers and CIDR-incapable Type 4 (Default only) providers/subscribers
  397.  
  398.  
  399.    The only difference between this case and the case described in
  400.    Section 5.1 is the fact that CIDR-incapable provider/subscriber would
  401.    not require any inter-domain routing information, other than the
  402.    Default inter-domain route. Therefore, controlled de-aggregation of
  403.    CIDR reachability information becomes a non-issues.
  404.  
  405.    It is still expected that a border router in a CIDR-capable provider
  406.    would be able to aggregate routing information it receives from a
  407.    CIDR-incapable Type 4 provider/subscriber. The aggregation is
  408.    expected to be governed and controlled via a bilateral agreement.
  409.    Specifically, the CIDR capable provider is expected to aggregate only
  410.    the information the other side (the CIDR-incapable
  411.    provider/subscriber) requests.
  412.  
  413.  
  414. 6  Conclusions
  415.  
  416.  
  417.    It is expected that the reduction in the global volume of routing
  418.    information will begin immediately upon completion of the first
  419.    phase. The second phase will allow to simplify bilateral arrangements
  420.    between connected service providers/subscribers by shifting the
  421.    responsibility for routing information aggregation towards the
  422.    parties that are better suitable for this, and by significantly
  423.    reducing the need for routing information de-aggregation. Thus, most
  424.    of the gain achieved during the second phase will come from
  425.    simplifying bilateral agreements. The third phase it intended to
  426.    complete the goals and objectives of the second phase.
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433. Expiration Date October 1993                                    [Page 7]
  434.  
  435.                            - 8 -
  436.  
  437.  
  438.  
  439. 7   Security Considerations
  440.  
  441.  
  442.    Security issues are not discussed in this document.
  443.  
  444.  
  445. 8   Acknowledgments
  446.  
  447.  
  448.    This document was largely stimulated by the discussion that took
  449.    place during the Merit/NSFNET Regional Tech Meeting in Boulder,
  450.    January 21-22, 1993.  We would like specifically acknowledge
  451.    contributions by Peter Ford (Los Alamos National Laboratory), Elise
  452.    Gerich (NSFNET/Merit), Susan Hares (NSFNET/Merit), Mark Knopper
  453.    (NSFNET/Merit), Bill Manning (Sesquinet/Rice University), and John
  454.    Scudder (NSFNET/Merit).
  455.  
  456.  
  457. 9   Authors' Addresses
  458.  
  459.  
  460.    Yakov Rekhter
  461.    T.J. Watson Research Center, IBM Corporation
  462.    P.O. Box 218
  463.    Yorktown Heights, NY 10598
  464.    Phone:  (914) 945-3896
  465.    EMail:  yakov@watson.ibm.com
  466.  
  467.    Claudio Topolcic
  468.    Corporation for National Research Initiatives
  469.    1895 Preston White Drive
  470.    Suite 100
  471.    Reston, VA 22091
  472.    Phone: (703) 620-8990
  473.    EMail: topolcic@CNRI.Reston.VA.US
  474.  
  475.  
  476. 10  References
  477.  
  478.  
  479.    [1] Fuller, V., Li, T., Yu, J., and Varadhan, K., `Supernetting: an
  480.    Address Assignment and Aggregation Strategy', RFC1338, June 1992
  481.  
  482.    [2] Gerich, E., `Guidelines for Management of IP Address Space',
  483.    RFC1366, October 1992
  484.  
  485.    [3] Rekhter, Y., Li, T., `An Architecture for IP Address Allocation
  486.    with CIDR', Internet Draft, January 1993
  487.  
  488.    [4] Rekhter, Y., Li, T., `A Border Gateway Protocol 4 (BGP-4)',
  489.    Internet Draft, December 1992
  490.  
  491.  
  492.  
  493.  
  494.  
  495. Expiration Date October 1993                                    [Page 8]
  496.  
  497.                            - 9 -
  498.  
  499.  
  500.  
  501.    [5] Rekhter, Y., Gross, P., `Application of the Border Gateway
  502.    Protocol in the Internet', Internet Draft, September 1992
  503.  
  504.    [6] Hares, S., `IDRP for IP', Internet Draft, June 1992
  505.  
  506.    [7] Varadhan, K., `BGP4 OSPF Interaction', Internet Draft, September
  507.    1992
  508.  
  509.    [8] Topolcic, C., `Notes on BGP-4/CIDR Coordination Meeting of 11
  510.    March 93', Internet Draft, March 1993
  511.  
  512.    [9] Knopper, M., `Aggregation Support in the NSFNET Policy Routing
  513.    Database', Internet Draft, March 1993
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557. Expiration Date October 1993                                    [Page 9]
  558.  
  559.